KODAK PHOTO CD ACCESS DEVELOPER TOOLKIT 1.3

PROGRAMMER L’ACCES AUX PHOTO CD

Par Rodolphe DURAND

Le Photo CD Toolkit est une bibliothèque de routines, ou API, proposée par Kodak aux développeurs, afin de leur faciliter  l’accès aux images PCD. Grâce à lui, rien de plus simple que de  lire ce format de fichier très particulier.

Choix de la résolution

A peine sortie la première version du Photo CD Toolkit (début  août) et Kodak fait déjà parvenir une mise à jour. Non pas que la première API  (Application Program Interface) était buguée outre mesure, ce  nouveau cru se justifie surtout pour accélérer le processus de  lecture (de 17% à 60%) et apporter de nouvelles fonctions.
Le Toolkit s'adresse aux développeurs désireux d'exploiter le Photo CD (PCD) dans  leurs applications existantes ou à venir. Outre une documentation  anglaise, un CD de 24 images et une disquette de Headers et  librairies C (MPW et Think), le Toolkit procure surtout une  licence. Pour Kodak, le prix à payer s'explique pour cette raison et –  applaudissons à deux mains – pour le suivi du produit. Remarquons  que le lecteur de CD-ROM doit répondre à la norme XA (eXtended  Architecture) et que l'option multi-sessions (XA-2) est souhaitable, sachant qu'il est possible de faire rajouter des images  un CD Kodak déjà enregistré (jusqu'à 100 images au gré de ses  développements de négatifs).
Avant de décrire les fonctions du Toolkit et de commenter les  résultats d'une application écrite à l'aide de ses librairies, nous introduirons les principes de bases  du PCD.

CONTENU

D'un point de vue de qualité, les 24 bits par pixel sont toujours  au rendez-vous quel que soit le format, mais ne correspondent pas  au classique cube RVB. Suivant le système CIE (Commission Internationale de l'Eclairage : 1931), Kodak a  préféré coder la couleur avec 2 octets en chrominance (C1 et C2)  tandis que le 3ème en exprime l'intensité (24-bit YCC). Si ce  codage des couleurs diffère des formats habituels en  informatique (RVB), il est capable d'en exprimer une aussi grande richesse et  la conversion en RVB est de toute façon aisée. Le choix du YCC  n’est pas un simple caprice de constructeur. D'abord, sa  similarité avec les standards télévisions (YUV ou UV signifie  aussi 2 autres Chrominances) le rapproche du grand public et cette  manière de stocker la luminance à part, en fait du même coup un  autre format en niveau de gris (8-bit Y). Ensuite, la vision  humaine ayant une bien meilleure acuité à la luminosité qu'à la  couleur, il est possible de "sous-échantillonner" les deux chrominances  sans perte significative lors de la restitution. C'est ce que   Kodak à donc réalisé en divisant par un facteur de 2 (linéaire,  donc de 2 x 2 = 4 en surface) les deux composantes de la  chrominance pour obtenir ainsi un fichier graphique directement réduit de  moitié, avant toute compression algorithmique.

CONTENANT

Le PCD recouvre deux formats. L'Overview Pac, ou fichier de  prévisualisation unique, contient une version compact (128x192  pixels, ouvrable aussi en 64x96) de chaque image sur le disque. Via une  indexation, il est alors possible de construire graphiquement une  directorie "d'icônes" pour laisser ensuite l'utilisateur  sélectionner son image préférée dans une meilleure résolution,  c'est à dire l'Image Pac.
Le "Pac" signifie ici un enregistrement à de multiples  résolutions. Il s'agit d'un encodage pyramidale stockant telles  quelles les images de résolution modérée pour un affichage  accéléré (128x192 appelé Base/16, 256x384=Base/4 et 512x768=Base, destinés aux lecteurs “de salon” pour TV) tandis que les  plus hautes (1024x1536=Base*4 et 2048x3072=Base*16) le sont en  différences compressées par rapport à l'image de la résolution  juste un cran en dessous. Par exemple, ce sont des résiduels qui  sont codés pour la Base*4, et pour la reconstituer, il faudra une  fois leurs décompressions effectuées (selon la méthode de  Huffman) l'extrapoler par la Base. Idem pour la Base*16 qui a  besoin de la Base*4 pour se recomposer. On comprend mieux  pourquoi on ne parle pas de JPEG, qui est une série d'algorithmes pour  compresser une image en un fichier unique, et responsable de  pertes cumulées chaque fois où le fichier résultat est  recompacté. Il s'agit ici au contraire de compresser les  résiduels d'une Base*n par rapport à une base qui elle ne changera jamais, et où le  résultat sera lui aussi toujours le même.

INSIDE PCD TOOLKIT

Pour une meilleure approche, nous décomposerons les fonctions du  Toolkit en cinq parties :
- Mémoire
Contrôler la mémoire quand on utilise des images de haute définition est vital. Le Toolkit procure  les routines pour gérer celle de ses ressources. Avec un  PCDsetAllowance() par exemple, on fixera la mémoire indispensable  pour une opération adressant un gros tampon interne au Toolkit,  et une fois le traitement terminé, la même fonction libérera la  place en vue d'une autre opération, relative cette fois à  l'application en elle-même. A titre d'indication, la largeur d'un  block de mémoire requis pour la lecture d'une image PCD  (PCDloadImage()) en 32-bit est de 1,5 Mo pour la Base, de 6,2 Mo pour la Base*4  et 25,1 Mo pour la Base*16. On constate ici que la Base*16 en  couleur n'est pas pour tout le monde, mais pour les  professionnels de l'image. Pour les autres, si le prix de la  barrette de 16 Mo ne baisse pas considérablement, il faudra se contenter du  Base*16 (peu habituel il est vrai) en niveaux de gris.
- Prévisualisation/Lecture
 Qu'il s'agit du fichier OverView ou Image, les routines les  adressant sont relativement similaires. Par exemple, outre l'orthographe voisine entre le PCDOopen() de l'OverView Pac  et le PCDopen() de l'Image Pac, les paramètres passés sont  exactement les mêmes. Il en est ainsi pour les fonctions qui  régissent le format couleur (RVB, YCC ou niveaux de gris), qui  établissent la résolution, qui appliquent des transformations de miroir  ou de rotation et enfin celles qui chargent les images en  mémoire. Le Toolkit nous propose ici deux moyens pour lire le  PCD. La routine PCDloadImage() (après avoir spécifié la  résolution, la définition, ...) lit directement dans l'environnement 32-bit  QuickDraw ou dans un "cgrafPort", ce qui est la solution la plus  avantageuse pour afficher une image avec un minimum de code via  un CopyBits(). D'un autre côté, PCDgetBlock() lit le format tel  quel dans un tampon arbitraire, ce qui peut-être préférable en vue  de conversions, de manipulation intensive dans un programme ou  bien si l'on désire travailler directement en YCC.
Enfin, indiquons que la version 1.3 apporte de nouvelles  fonctions pour gérer en un seul niveau les ouvertures/fermetures de fichiers, qu'elles  soient PCD ou non. Après un FSOpen() de la Toolbox du Macintosh,  un PCDrefOpen() créera ainsi toute la stucture spécifique au  Toolkit (FSOpen+PCDrefOpen=PCDopen). Inversement, la fonction PCDrefClose la détruira en laissant le soin à l'application de  fermer le fichier PCD.
- Conversion
Le Toolkit procure deux fonctions de conversion qui utilise en  entrée le format 24-bit YCC. PCDYCCtoRGB() donne le même résultat  qu'une image obtenue avec un PCDloadImage() (RVB corrigé avec un gamma de 2,2) et PCDdither()  converti en une image niveau de gris "dithered" d'un bit par  pixel. Précisons, depuis la nouvelle version, que  "l"adoucissement" est automatique (par défaut, ou non par choix)  pour le chargement ou l'exportation d'images désirées à une définition inférieure  à 16 bits/pixel (lissage des transitions entre régions de  différentes couleurs pour une apparence plus naturel).
- Exportation
Une fois l'image ouverte par un PCDopen(), il s'agit de créer un fichier Macintosh, d'y ouvrir son DataFork et d'utiliser enfin  PCDexport() pour obtenir du PICT, TIFF ou de l'EPSF. De par ses  paramètres et outre le format d'export voulu, cette fonction  permet de fixer :  la profondeur du pixel (de 1 à 32, sachant que  les définitions inférieures à 16 ont besoin d'une table de  translation couleur via un GetCTable, idem avec un PCDloadImage),  la partie de l'image à exporter (ou sa totalité) et de définir le  type de pixel voulu. "Interleaved", le plus courant, où les 3  composants (RVB) de chaque pixel sont stockés en un block continu et  "Planar" en vue d'une séparation des couleurs et chaque élément  est cette fois rassemblé avec ses voisins dans un plan.
- Copyright
Oui, il y a un sous-directory appelé "RIGHTS", qui contient des fichiers texte décrivant les copyrights où les restrictions  d'utilisations pour une ou plusieurs images. La fonction  PCDreadImageInfo() n'est pas là innocemment, et Kodak encourage  fortement son utilisation avant l'affichage de n'importe quelle  image. Mieux, il précise que l'absence d'un tel fichier relatif à une  image ne signifie pas que celle-ci n'est pas protégée. Attention  aux rois du photomontage !
 
PHOTO-EXCHANGE : L'APPLICATION

S'inspirant de l'exemple de visualisation des images PCD fournit  dans le Toolkit, nous avons rajouté le source nécessaire (conforme  système 7) pour implémenter les fonctions d'exportations en PICT,  TIFF et EPSF. A l'issue de quelques compilations de Think C 5.0.2  et de grandes bénédictions à ResEdit 2.1.1, nous voilà partis à l'exploration des images du CD-ROM. Après de longues  tergiversations, nous avons choisi finalement le profil droit  d'une pertinente petite fille joliment maquillée et les tests ont  enfin pu commencer (Précisons, pour référence, que nous avons  transféré le contenu du CD-ROM sur le disque dur interne de la machine  pour de meilleurs temps d'accès disque et que la machine en  question est un Quadra 900 de 36 Mo de mémoire vive - 26 Mo sont  nécessaires pour adresser du Base*16 en 32-bit, voir paragraphe  mémoire). Premières constatations, si le temps d'affichage est  négligeable pour une image haute en couleur ne dépassant pas la  Base, il  lui faut 38 secondes sur un Quadra 900 en Base*4  (presque 1 mn avec la 1ère version) et légèrement plus de 3  minutes en Base*16  (presque 5 mn avec la 1ère version). Il est vrai qu'il  s'agit ici de 1,10 mètre sur 72 centimètres, ce qui ne correspond  pas vraiment à l'applicatif de tous les jours. Notons aussi à  titre de comparaison, que PhotoShop, à partir d'un fichier PICT  et sans effectuer de décodage, ouvre cette dimension en un peu  moins de 3 minutes. Passons maintenant à l'exportation et restons  gourmand en Base*16 24-bit pour demander un fichier PICT.  Résultat : 18 Mo sont générés à partir du fichier de 3,9 Mo de  notre petite fille. Ce n'est pas mal contenu du fait que ces 3,9 Mo sont  relatifs de 5 résolutions différentes. On reste dans le même  ordre de grandeur avec du TIFF mais surprise, le fichier EPSF  généré n'est pas reconnu par PhotoShop. Après plusieurs  tentatives infructueuses de chargement dans divers softs graphiques,  FrameMaker arrive finalement à le charger sous la forme d'une  boite toute grise mais signale des erreurs PostScripts dès que  l'on veut l'imprimer. Enfin, personne n'est parfait, et gageons  que Kodak s'occupe déjà de ce problème. Pour finir, nous dirons qu'il a été  plutôt agréable de développer notre logiciel, PhotoExchange.  L’homogénéité des fonctions du Toolkit font que le programmeur  n'a même pas besoin de comprendre la façon dont sont stockées les  images, ou de se lancer corps et âme dans le déchiffrage de l'une  de ses structures.

Le PCD Toolkit répond clairement aux besoins d'un développeur de  logiciels et celui-ci aura vite compris que Kodak fait figure  d'une sacrée locomotive dans le domaine de l'image numérique. Il est en effet le seul à placer la qualité  chimique de la photographie dans une expression numérique  accessible à tous (4 Frs la photo CD) et à n'importe quel type de  besoins (QuickTime, TV, TVHD, format publicitaire, ...). Une  nouvelle version serait pourtant encore la bienvenue, moins pour les plus  paresseux ne disposant pas de leur propre fonction d'export EPSF,  mais surtout pour sauvegarder tout simplement en format PCD. Si  ce format est en voie de standardisation, et bien qu'un réseau mondial d'accès à des millions d'images PCD est en train de se   mettre en place, les flasheurs, pour ne citer qu'eux, aimeraient  sûrement se servir de leurs propres scanners afin de l'utiliser  et de l'échanger. Espérons alors que la sortie des nouveaux formats PCD et notamment le PCD-Master-Pro intégrant la Base*32  coïncidera avec celle du Photo CD Toolkit 2.O.

KODAK PHOTO CD ACCESS DEVELOPER TOOLKIT 1.3
FONCTION : Licence et Kit d'exploitation du PCD dans une  application.
DISTRIBUTEUR : Images Informations Services
3, Chemin de la Jonchère
B.P. 24
92502 Rueil-Malmaison
Tél. : 47 32 02 68
PRIX : 6 950 F HT

 

Option PICT, TIFF et EPSF pour l'export.